Live MQTT-Steuerung

tipp

Die Live-MQTT-Steuerung ist für die Live-Steuerung gedacht. Für die zeitgesteuerte Sendung von Zeitplänen siehe stattdessen Geplante MQTT-Steuerung.

Dieser Leitfaden hilft Ihnen, MQTT auf Ihrem SmartgridOne Controller zu konfigurieren, um Batterien und Solarpanel-Installationen aus der Ferne zu steuern und zu überwachen.

Was Sie benötigen

1. SmartgridOne Controller mit Internetverbindung.
2. MQTT-Anmeldeinformationen: Diese können angefordert werden, indem Sie eine E-Mail an support@eniris.be senden.
3. Python-Entwicklungsumgebung (oder einen anderen MQTT-Client). Dieser Leitfaden verwendet ein einfaches Beispiel, das in Python geschrieben wurde, um Ihnen den Einstieg in MQTT und das Senden von Befehlen zu erleichtern. Wir empfehlen die Verwendung von Python wegen der Benutzerfreundlichkeit, aber jeder andere MQTT-Client wird unterstützt.

Zusätzliche Informationen

MQTT ist ein schnelles Kommunikationsprotokoll über das Internet. Es handelt sich um ein Publish/Subscribe-Nachrichtensystem, das eine direkte Verbindung zwischen Ihrer Maschine und dem SmartgridOne Controller ermöglicht. Ihre Anlagen werden in Solar-, Batterien-, EV- und HVAC-Gruppen kategorisiert.

Erstkonfiguration (Ausgangspunkt für neue Benutzer)

Ich habe einen SmartgridOne Controller, den ich für die MQTT-Remote-Steuerung einrichten möchte.

1. Überprüfen Sie Ihr Netzwerk

Stellen Sie sicher, dass Ihr Netzwerk den MQTT-Netzwerkverkehr über Port 1883 zulässt. Sie können dies mit dem folgenden Befehl tun:

nc -zv mqtt.eniris.be 1883

Wenn dieser Befehl nicht verfügbar ist, können Sie alternativ diesen Python-Code herunterladen und ausführen.

Wenn Sie sich unsicher sind, konsultieren Sie Ihren Netzwerktechniker oder verwenden Sie vorübergehend den 4G/5G-Hotspot Ihres Telefons, wenn Verbindungsfehler auftreten.

hinweis

Wenn Port 1883 von Ihrem Netzwerk aus nicht erreichbar ist, bieten wir eine Sicherung auf Port 80 an. Dies kann in Ihrem MQTT-Client in einem späteren Schritt in diesem Handbuch konfiguriert werden.

2. Fügen Sie Ihre Geräte hinzu

Loggen Sie sich in die Inbetriebnahmeschnittstelle ein und stellen Sie sicher, dass die Geräte hinzugefügt sind zu dem SmartgridOne Controller.

3. Fügen Sie das MQTT-Aussensignal hinzu

4. Aktivieren Sie das MQTT-Remote-Signal

Das Feld 'VPP-ID' muss leer gelassen werden.

Der Timeout des Fallback-Mechanismus teilt dem SmartgridOne Controller mit, wie lange es auf neue Befehle warten soll. Wenn der SmartgridOne Controller aufhört, Befehle zu empfangen, wechselt er automatisch nach diesem Timeout zur Standardstrategie.

Wählen Sie danach alle Geräte aus, die Sie in die MQTT-Remote-Steuerung einbeziehen möchten.

5. Remote-Signal wird hinzugefügt

Die MQTT-Remote-Steuerungsschnittstelle wurde nun auf dem SmartgridOne Controller aktiviert.

Wir sind jetzt bereit, einige grundlegende Befehle mit einem einfachen Beispiel zu senden. Die Spalte Status zeigt Ihnen an, ob ein Befehl aktiv ist.

Python-Demo-Skript

Ein guter erster Ausgangspunkt wäre, Ihre neu eingerichtete Integration mit einem einfachen Beispiel zu testen.

Dieser Testcode führt eine einfache Aufgabe aus, indem er kontinuierlich die folgenden Befehle sendet:

• Batterie: Laden mit 5 kW
• Solar: Leistung auf 0 kW setzen

Der SmartgridOne Controller reagiert kontinuierlich mit einer 'Feedback'-Nachricht, die die beobachteten Stromnetz- und Anlagenleistungswerte enthält. Diese Funktion ist ebenfalls in diesem Beispiel enthalten.

Bitte laden Sie die Datei unten in Ihrer bevorzugten Python-IDE herunter. Füllen Sie Ihre Seriennummer und die MQTT-Anmeldeinformationen aus und führen Sie das Skript aus:

Wenn oben beschrieben erfolgreich ist, können Sie mit dem Senden anderer Arten von Befehlen fortfahren. Alle Befehle sind in unserer Dokumentation zur MQTT-Remote-Steuerung beschrieben.

MQTT-Dokumentation für das Senden von Befehlen

Dieser Abschnitt beschreibt das MQTT-Nachrichtenformat und die Payload-Anforderungen zum Remote-Steuern von Energiepolitiken auf Geräten im Netzwerk des SmartgridOne Controller.

MQTT-Thema

Das MQTT-Thema, das zum Senden von Befehlen verwendet wird, ist wie folgt strukturiert:

standard1/rp_one_s/remoteControlMetrics/'controller SN'

Dabei sollte 'controller SN' durch die tatsächliche Seriennummer des SmartgridOne Controller ersetzt werden, den Sie steuern möchten.

Struktur der MQTT-Payload

Befehle werden als JSON-Payloads gesendet. Die Struktur der Payload ist so konzipiert, dass verschiedene Energieverwaltungsrichtlinien und Zielwerte für verschiedene Komponenten des Smart Grid-Systems spezifiziert werden. Hier ist der Umriss der Payload mit detaillierten Feldbeschreibungen:

{
    "extraTags": {
        "nodeId": "<Controller SN>_site_0"
    },
    "time": "<Unix Timestamp>",
    "fields": {
        "<Component Policy>": "<Policy Type>",
        "<Component Power Setpoint>": <Setpoint in watts>
    }
}

Feldbeschreibung

tipp

Mehrere Gerätetypen (z. B. Batterien + Solar) können gleichzeitig gesteuert werden.

• extraTags (Objekt):
  • nodeId (String): Eine eindeutige Kennung für den Knoten im Netzwerk des SmartgridOne Controller. Dies entspricht Ihrer Seriennummer, gefolgt von '_site_0' für die meisten SmartgridOne Controller-Geräte.
• time (Integer): Unix-Zeitstempel in Sekunden, der angibt, wann die Nachricht gesendet wird.
• fields (Objekt):
  • <Component>_policy (String): Richtlinientyp für die Komponente. Dies ist optional, und wenn nicht angegeben, verwendet das System die Standardeinstellung des SmartgridOne Controller.
  • <Component>_power_setpoint_w (Float): Gewünschter Leistungszielwert in Watt für die Komponente. Dies ist optional und nur relevant, wenn eine entsprechende Richtlinie angegeben wird.

Komponenten und Richtlinien

info

Anlagen des gleichen Typs (z. B. zwei Batterien) werden als eine Komponente zusammengefasst. Wenn beispielsweise zwei 5-kWh-Batterien installiert sind, wird dies als eine 10-kWh-Batterie behandelt.

Jede Komponente im fields-Objekt kann eine Richtlinie und einen Leistungszielwert enthalten. Die folgenden Komponenten können gesteuert werden:

• solar_policy und solar_power_setpoint_w:

  • Steuert die Richtlinie und den Zielwert der Solarstromerzeugung. Unterstützte Richtlinien:
    • Richtlinie Zielwert: Setzen Sie die maximale Leistung, die von allen angeschlossenen Solaranlagen zusammen erzeugt wird. Das Feld solar_power_setpoint_w sollte auf das Produktionsleistungsgrenze in Watt gesetzt werden.
    • Richtlinie Einspeisebeschränkung: Produzieren Sie mit voller Leistung, wobei die aktuellen Netzgrenzen berücksichtigt werden.
    • Richtlinie Kosten: Ermöglicht die Minimierung der Kosten für den Tag im Voraus (EPEX-Spotmarkt) für die Solarproduktion. Wenn negative Einspeisepreise auftreten, drosseln wir die Produktion auf den Eigenbedarf. Wenn sowohl der Abnahmepreis als auch der Einspeisepreis negativ sind, schalten wir alle Solaranlagen ab. Das Feld solar_power_setpoint_w wird ignoriert.
    • Richtlinie aus: Deaktiviert alle Interaktionen für alle Solaranlagen. Warnung: Grenzen werden in diesem Modus nicht überwacht. Das Feld solar_power_setpoint_w wird ignoriert.

• storage_policy und storage_power_setpoint_w:

• Steuert die Richtlinien des Energiespeichersystems sowie die Lade- oder Entladeleistung.

  • Richtlinien-Setpunkt: Setzen Sie die gesamte Ladeleistung (positiver Setpunkt) oder Entladeleistung (negativer Setpunkt) für die Gruppe von Batterien. Wenn mehrere Batterien angeschlossen sind, wird der Setpunkt nach verfügbarer Lade-/Entladeleistung aufgeteilt, um die Batterien gleichmäßig zu belasten. Das Feld storage_power_setpoint_w wird auf die gewünschte Batterieleistung gesetzt.
  • Richtlinienkosten: Ermöglicht die Kostenoptimierung für Tagespreise (EPEX Spotmarkt) bei den Batterien, indem sie in den günstigen Stunden geladen und in den teuren Stunden genutzt werden. Das Feld storage_power_setpoint_w wird ignoriert.
  • Richtlinie Eigenverbrauch: Ermöglicht einen einfachen Eigenverbrauchsalgorithmus für die Batterien. Überschüssige Solarproduktion wird während des Tages in der Batterie gespeichert, und wenn die Sonne nicht scheint, wird Energie aus der Batterie entnommen. Das Feld storage_power_setpoint_w wird ignoriert.
  • Richtlinie aus: Deaktiviert alle Interaktionen für alle Batterieanlagen. Warnung: Grenzen werden in diesem Modus nicht überwacht. Das Feld storage_power_setpoint_w wird ignoriert.

• heat_pump_policy:

  • Schaltet die Wärmepumpensysteme ein/aus. Die minimalen und maximalen Betriebszeiten werden immer eingehalten.
    • Richtlinienkosten: Ermöglicht die Kostenoptimierung für Tagespreise (EPEX Spotmarkt) bei den Wärmepumpen. Der lokale dynamische Preisalgorithmus entscheidet über die besten Betriebszeiten.
    • Richtlinie Eigenverbrauch: Schaltet die Wärmepumpen ein, wenn überschüssige Solarenergie produziert wird.
    • Richtlinie ausgeschaltet: Schaltet die Wärmepumpen ab.
    • Richtlinie eingeschaltet: Schaltet die Wärmepumpen ein.

• switched_load_policy:

  • Schaltet steuerungsgesteuerte Systeme ein/aus. Dies könnte das integrierte Relais oder netzwerkverbundene Relais sein.
    • Richtlinienkosten: Ermöglicht die Kostenoptimierung für Tagespreise (EPEX Spotmarkt) bei dem Relais.
    • Richtlinie Eigenverbrauch: Schaltet das Relais ein, wenn überschüssige Solarenergie produziert wird.
    • Richtlinie ausgeschaltet
    • Richtlinie eingeschaltet

• variable_power_load_policy und variable_power_load_power_setpoint_w:

  • Verwalten Sie die Richtlinie und den Setpunkt des Stromverbrauchs von Elektrofahrzeugen.
    • Richtlinien-Setpunkt: Setzen Sie die gesamte Ladeleistung für die Gruppe von Elektrofahrzeugen. Das Feld variable_power_load_power_setpoint_w wird auf die gewünschte Ladeleistung gesetzt.
    • Richtlinienkosten: Ermöglicht die Kostenoptimierung für Tagespreise (EPEX Spotmarkt) bei den Batterien, indem sie in den günstigen Stunden geladen werden. Das Feld variable_power_load_power_setpoint_w wird ignoriert.
    • Richtlinie Eigenverbrauch: Ermöglicht das Laden, wenn überschüssige Solarenergie produziert wird. Das Feld variable_power_load_power_setpoint_w wird ignoriert.
    • Richtlinie aus: Deaktiviert alle Interaktionen für alle E-Fahrzeuganlagen. Das Feld variable_power_load_power_setpoint_w wird ignoriert.

• site_policy und site_power_setpoint_w:

  • Verwalten Sie die Exportgrenzen der Anlage.
    • Richtlinie Export: Setzen Sie die Exportgrenze für die Anlage. Das Feld site_power_setpoint_w wird auf die Exportgrenze gesetzt.
    • Richtlinie Standard: Setzt die Anlagenbegrenzung auf die standardmäßige Exportleistung zurück, die in der Controller-Konfiguration festgelegt ist.

Gerätesteuerung

Bestimmte Geräte können ebenfalls unabhängig von Gruppen von Geräten basierend auf ihren Typen gesteuert werden. Die Nachricht hat eine identische Struktur:

• nodeId_policy und nodeId_power_setpoint_w

info

Wenn zwei Befehle an dasselbe Asset gesendet werden (z.B. ein gerätespezifischer Befehl an einen Solarwechselrichter und ein Befehl an alle Solargeräte), wird die gerätespezifische Steuerung der Steuerung über die Gerätegruppenkontrolle vorgezogen.

Fallback-Verhalten

Für jedes Bauteil, wenn _policy und _power_setpoint_w nicht angegeben sind, verwendet das System automatisch die Fallback-Richtlinie, die im SmartgridOne Controller konfiguriert ist. Dies stellt sicher, dass jedes Gerät oder jede Gerätgruppe sicher funktioniert und auch weiterhin arbeitet, selbst wenn keine spezifischen Anweisungen gegeben sind.

Wenn über 60 Sekunden (oder den konfigurierten Timeout Zeitraum) kein Befehl gesendet wird, werden die Standardrichtlinien für Anlagen wieder aktiviert.

Beispielpayload

Nachfolgend ein Beispiel eines Payloads zum Setzen verschiedener Richtlinien und Setpunkte:

{
    "extraTags": {
        "nodeId": "OM12404080000000000_site_0"
    },
    "time": 1714652046,
    "fields": {
        "solar_policy": "setpoint",
        "solar_power_setpoint_w": 5000,
        "storage_policy": "setpoint",
        "storage_power_setpoint_w": -5000
    }
}

In diesem Beispiel wird die Solarleistung auf bis zu 5000 Watt gesetzt, und das Energiespeichersystem wird so eingestellt, dass es entweder mit einer Leistung von 5000 Watt lädt oder entlädt, je nach Vorzeichen des Setpunktwerts. Wenn entweder die solar_policy oder die storage_policy weggelassen wird, würde das jeweilige Gerät zu den Standardeinstellungen zurückkehren, die durch den SmartgridOne Controller bestimmt wurden.

MQTT-Dokumentation zum Empfang von Rückmeldungen

Dieser Abschnitt beschreibt die Struktur und den Inhalt der Rückmeldungsnachrichten, die von der SmartgridOne Controller über MQTT gesendet werden. Diese Nachrichten werden nach der Verarbeitung eines Befehls an das Thema standard1/outbound/remoteControlMetrics/feedback/<Controller SN> veröffentlicht.

MQTT-Rückmeldethema

Das MQTT-Rückmeldethema ist wie folgt strukturiert:

standard1/outbound/remoteControlMetrics/feedback/<Controller SN>

Wobei <Controller SN> durch die Seriennummer des SmartgridOne Controller ersetzt werden sollte, der die Rückmeldung sendet.

Struktur der MQTT-Rückmeldelast

hinweis

Alle Anlagen werden nach ihrem Typ gruppiert. Das bedeutet, dass zwei individuelle Solarinstallationen von 3 kW als eine 6 kW-Anlage behandelt werden.

Rückmeldungsnachrichten sind im Format von JSON-Payloads formatiert. Diese Payloads bieten detaillierte Rückmeldungen zum Zustand des Systems nach Anwendung der Setpunktbefehle unter Berücksichtigung der Netz-/Gerätegrenzen. Nachfolgend die Struktur der Rückmeldelast mit Beschreibungen ihrer Felder:

{
    "time": "<Unix Timestamp>",
    "data": {
        "state": {
            "grid": {
                "active_power_W": <Gitteraktive Leistung in Watt>,
                "today_imported_energy_Wh": <Heute importierte Energie in Wattstunden>,
                "today_exported_energy_Wh": <Heute exportierte Energie in Wattstunden>,
                "import_limit_W": <Netzimportgrenze in Watt>,
                "export_limit_W": <Netzexportgrenze in Watt>,
            },
            "vpp_id": "<Identifikator des virtuellen Kraftwerks>",
            "storage": {
                "energy_stored_Wh": <Energie in Wattstunden gespeichert>,
                "energy_capacity_Wh": <Gesamte Energiekapazität in Wattstunden>,
                "mean_soc_perc": <Durchschnittlicher Ladezustand in Prozent>,
                "active_power_W": <Aktive Leistung in Watt>,
                "executed_power_W": <Leistungs-Setpoint, der an Geräte gesendet wurde in Watt>,
                "executed_policy": <Von dem Controller ausgeführte Richtlinie>,
                "max_charge_power_W": <Maximale Ladeleistung in Watt>,
                "max_discharge_power_W": <Maximale Entladeleistung in Watt>,
                "today_charged_Wh": <Heute geladene Energie in Wattstunden>,
                "today_discharged_Wh": <Heute entladene Energie in Wattstunden>,
                "nr_devices": <Anzahl der kontrollierten Speichereinrichtungen>
            },
            "solar": {
                "active_power_W": <Aktive Solarleistung in Watt>,
                "executed_power_W": <Leistungs-Setpoint, der an Geräte gesendet wurde in Watt>,
                "executed_policy": <Von dem Controller ausgeführte Richtlinie>,
                "capacity_W": <Solar-Kapazität in Watt>,
                "today_energy_Wh": <Heute produzierte Energie in Wattstunden>.
                "nr_devices": <Anzahl der installierten gesteuerten Solargeräte>
            },
            "heat_pump": {
                "executed_policy": <Von dem Controller ausgeführte Richtlinie>,
                "operation_modes": <Betriebsarten der Wärmepumpe>,
                "executed_power_W": <Leistungssollwert, der an Geräte in Watt gesendet wurde>,
                "nr_devices": <Anzahl der installierten gesteuerten Wärmepumpen>
            },
            "switched_load": {
                "executed_policy": <Von dem Controller ausgeführte Richtlinie>,
                "devices_on": <Anzahl der eingeschalteten Geräte>,
                "devices_off": <Anzahl der ausgeschalteten Geräte>,
                "executed_power_W": <Leistungssollwert, der an Geräte in Watt gesendet wurde>,
                "nr_devices": <Anzahl der installierten gesteuerten eingeschalteten Lasten>  
            }
        },
        "response_code": <Antwortcode>
    },
    "fields": {},
    "requestTime": "<Unix-Zeitstempel>",
    "time": "<Unix-Zeitstempel>",
    "siteNodeId": "<Controller SN>_site_0"
}

### Beschreibung der Felder
- time (Integer): Unix-Zeitstempel, der die Zeit angibt, zu der die Rückmeldungsnachricht gesendet wurde.
- fields (Object):
    - state (Object):
        - vpp_id (String): Identifier für das virtuelle Kraftwerk, das mit diesem Gerät verbunden ist.
        - grid (Object):
            - active_power_W (Float): Repräsentiert die aktuelle aktive Leistung im Netz in Watt.
            - today_imported_energy_Wh (Float): Die gesamte Energie, die heute aus dem Netz entnommen wurde, in Wattstunden. Hinweis: Heute ist in UTC-Zeit angegeben.
            - today_exported_energy_Wh (Float): Die gesamte Energie, die heute wieder ins Netz eingespeist wurde, in Wattstunden. Hinweis: Heute ist in UTC-Zeit angegeben.
            - import_limit_W (Float): Die Importgrenze des Netzes in Watt,
            - export_limit_W (Float): Die Exportgrenze des Netzes in Watt,
        - storage (Object):
            - energy_stored_Wh (Float): Aktuelle Menge an Energie, die in Wattstunden gespeichert ist.
            - energy_capacity_Wh (Float): Gesamte Speicherkapazität des Speichersystems in Wattstunden.
            - mean_soc_perc (Float): Ladezustand als Prozentsatz. Dies ist der gewichtete Durchschnitt aller verbundenen Batterien. (wenn mehrere Batterien verbunden sind: z.B. Batterie 'a' hat eine Energiespeicherkapazität von 10 kWh und einen Ladezustand von 20%; Batterie 'b' hat eine Energiespeicherkapazität von 20 kWh und einen Ladezustand von 50%, dann beträgt der mean_soc_perc 40%)
            - active_power_W (Float): Aktuelle aktive Leistung des Speichersystems in Watt, die den Lade- oder Entladevorgang anzeigt.
            - max_charge_power_W (Float): Maximale Leistung, mit der der Speicher geladen werden kann.
            - max_discharge_power_W (Float): Maximale Leistung, mit der der Speicher entladen werden kann.
            - executed_power_W (Float): Die Summe der gesamten Leistung, die von den Speichermitteln (ent)laden werden soll, die von unserem Steueralgorithmus gesendet wird. Nur anwendbar, wenn die 'follow_setpoint'-Richtlinie aktiv ist.
            - executed_policy (Str): Die Richtlinien, die auf die steuerbaren Elemente angewendet wurden.
            - today_charged_Wh (Float): Die gesamte heute in die steuerbare Batterie eingespeiste Energie. Hinweis: Heute ist in UTC-Zeit angegeben.
            - today_discharged_Wh (Float): Die gesamte heute aus der steuerbaren Batterie entnommene Energie. Hinweis: Heute ist in UTC-Zeit angegeben.
            - nr_devices (Int): Die Anzahl der steuerbaren Batterieanlage.
        - solar (Object):
            - active_power_W (Float): Aktuelle aktive Leistung, die von Solarpanelen in Watt erzeugt wird.
            - capacity_W (Float): Gesamte Kapazität des Solargenerierungssystems in Watt.
            - executed_power_W (Float): Die Summe der gesamten Leistung, die von den Solarressourcen angefordert wurde und von unserem Steueralgorithmus gesendet wird. Nur anwendbar, wenn die 'follow_setpoint'-Richtlinie aktiv ist.
            - executed_policy (Str): Die Richtlinien, die auf die steuerbaren Elemente angewendet wurden.
            - today_energy_Wh (Float): Die gesamte heute aus den steuerbaren Solarressourcen produzierte Energie. Hinweis: Heute ist in UTC-Zeit angegeben.
            - nr_devices (Int): Die Anzahl der steuerbaren Solarressourcen.
        - heat_pump (Object):
            - executed_policy (Str): Die Richtlinien, die auf die steuerbaren Elemente angewendet wurden.
            - operation_modes (Str): Der Modus der Wärmepumpe (Blockmodus, Boostmodus, Selbstkontrollmodus)
            - executed_power_W (Float): Die erwartete Leistung, die sie derzeit verwendet.
            - nr_devices (Int): Die Anzahl der steuerbaren Wärmepumpen.
        - switched_load (Object):
            - executed_policy (Str): Die Richtlinien, die auf die steuerbaren Elemente angewendet wurden.
            - devices_on (Int): Die Anzahl der eingeschalteten Geräte.
            - devices_off (Int): Die Anzahl der ausgeschalteten Geräte.
            - executed_power_W (Float): Die Leistung, die derzeit verwendet wird (sofern verfügbar).
            - nr_devices (Int): Die Anzahl der steuerbaren Ein/Aus-Schaltlasten.
        - nodeId (Object):
            - Wenn eine nodeId im Befehl enthalten ist, enthält das Feedback den entsprechenden Zustand des Geräts.
    - response_code (Int):
        - Gibt den Status der Operation an. Ein response_code von 0 bedeutet typischerweise Erfolg, während andere Werte unterschiedliche Arten von Fehlern oder Statusinformationen anzeigen können (diese sollten in einem separaten Verweis detailliert beschrieben werden).

### Beispiel für ein Rückmeldungs-Payload
Hier ist ein Beispiel für eine Rückmeldungsnachricht, die nach einem Befehl zum Setzen verschiedener Leistungssollwerte folgt:

<ClickableImage src="/img/generic/mqtt-example-feedback.png" alt="Bild 1" maxWidth="450px" />

Dieses Feedback zeigt den aktuellen Betriebszustand des Systems nach der Ausführung der Sollwerte und beschreibt die Auswirkungen auf die Solarproduktion, die Speicherung und die Gesamtheit der Netzinteraktion.

## Unterstützte MQTT-Versionen und Verhalten bei nicht autorisierten Themen
Bei der Verwendung von MQTT ist es wichtig, die Unterschiede in den Spezifikationen zwischen den Versionen 3.1, 3.1.1 und 5.0 zu berücksichtigen, insbesondere in Bezug auf das Verhalten des Brokers, wenn Clients an nicht autorisierte Themen veröffentlichen.

Laut der MQTT 3.1.1-Spezifikation (siehe OASIS MQTT 3.1.1-Spezifikation, Abschnitt MQTT-3.3.5-2) muss ein Broker die Verbindung beenden, sobald ein Client ein PUBLISH an ein Thema sendet, für das er keine Berechtigung hat. Dieses Verhalten kann unerwartete Trennungen für Clients zur Folge haben, die versuchen, an falsch konfigurierten oder nicht autorisierten Themen zu veröffentlichen.

In MQTT 3.1 ist diese Anforderung nicht vorhanden. Wenn ein Client in dieser Version an ein nicht autorisiertes Thema veröffentlicht, ignoriert der Broker typischerweise die Nachricht (stilles Fallenlassen), ohne die Verbindung zu beenden. Dies macht MQTT 3.1 in einigen Fällen geeigneter, wenn Robustheit gegenüber Konfigurationsfehlern oder vorübergehend fehlenden Berechtigungen wichtiger ist als strikte Sicherheitsdurchsetzung.

Obwohl MQTT 5.0 die Möglichkeit zur Verwendung von Grundcodes (wie PUBACK mit einem Ablehnungsgrund) einführt, erfordert dies Unterstützung sowohl auf der Client- als auch auf der Serverseite. Der Umstieg auf MQTT 5.0 erfordert daher zusätzlichen Implementierungsaufwand.

__Folgen der Missachtung der Kompatibilität:__
Wenn ein Client sich mit MQTT 3.1.1 verbindet und versucht, Nachrichten an nicht autorisierte Themen zu veröffentlichen, wird der Broker die Sitzung abrupt beenden. Dies kann zu Instabilität, Verbindungsverlust oder erhöhtem Aufwand durch wiederholte Verbindungsversuche führen.

__Empfohlener Ansatz:__
Für Systeme, in denen Clients (vorübergehend) versuchen können, an nicht autorisierte Themen zu veröffentlichen, oder in denen die Fehlerbehandlung nicht streng umgesetzt ist, empfehlen wir die Verwendung von MQTT 3.1. Dies sorgt für stabilere Verbindungen und vermeidet unbeabsichtigte Trennungen während der Laufzeit.